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Abstract 


Management of large networks, consisting of many interconnected network segments, 
is done by collecting traffic statistics, gathering routing information, reporting errors, 
monitoring link equipments, servers, systems, and locating faults. A management 
station is used to collect the nessary information from the different systems on the 
network and display suitably relevant processed information. The communication be- 
tween the manager and managed systems uses special network management protocols. 
SNMP (Simple Network Management Protocol) is currently the most popular network 
management protocol for TCP/IP based networks. SNMP was originally targeted at 
the TCP/IP based lUitworks, but its rapid adoption and easy (ixtendibility have ca\iscd 
its use to spread into proprietary environments. 

Earlier implementations of SNMP in the “ERNET" Lab were PC baaed SNMP 
manag(!r with basic functionalities by Barari [barariOS] and Micro Vax (Ultrix) b<ised 
SNMP manager with user interface by Bansal [bansal94]. A proxy agent was imple- 
mented on the same machine by Bansal to poll machines without an SNMP agent. In 
this thesis, an MS-Windows ba.sed SNMP manager has been successfully implemented. 
The manager uses ‘winsock’ library functions for communication with agents and proxy 
agent (s). This network manager displays the status of the network by probing the dif- 
ferent hosts via remote proxy agent(s) and can directly fetch MIB values from hosts 
with SNMP agents. In this thesis, the manager has been implemented with an added 
feature of polling remote proxy agent running on Linux environment. This enables 
the manager to distribute the polling schedules to proxy agents on systems located in 
different segments, thereby significantly reducing intersegment management traffic. 
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Chapter 1 

INTRODUCTION 


III today’s world, each major organisation be it a commercial firm or educational institu- 
tion has it’s own local area network to support computer to computer communications. 
Also, interconnection between these networks is not a privilege but a necessity as min- 
utes do make a difference today. With this internetworking and fast communication 
ruling our lives and especially business world, a failure of link or a bottleneck for traffic 
can play havoc with the network. A few business deals and some important emails de- 
livered late can be potential loss to many. In this context. Network Management comes 
into play which continually apprises the authority about the health of the network. 

1 . 1 Internetworking 

Before proceeding further let us understand internetworking and internet. In simple, 
internetworking is the technology that makes it possible to interconnect many dis- 
parate physical networks. It hides the low-level details and makes the collection of 
networks appear like a single large network. Such an interconnection scheme is called 
an internetwork or internet. 

An internet generally consists of a large number of systems such as PCs, main- 
frames, workstations, network systems etc interconnected through gateways, routers, 
etc. One of the primary aim of internetworking is network independence. That is, 
the set of operations used to establish communication or to transfer data should re- 
main independent of the underlying network technologies and destination machine. 
The largest internetworking technology is the Internet Suite of Protocols, commonly 
referred to as TCP/IP. 

1.2 Network Management 

Network Management as a term has many definitions depending on whose operational 
function is in question. In the context of the internet. Network Management may be 
thought of as facilities for updating of routing information, traffic statistics collection, 
error reports and fault location facilities, accounting for the use of costly communication 
resources and network access control. 
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internet 



Proprietary Network inaiiageinont systems such as Netview, AT&T Accumaster 
and Digital Eciuipinent Corporation’s DMA, have been in oi)eration for many years. 

The International Standards Organisation has defined five key areas [dalhisSS] of 
network management. Thes(i arc fault management, configuration manageinent, se- 
curity management, performance manageinent, and accounting management. It can 
formally be defined as the process for controlling a complex data network so as to max- 
imize its efficiency and productivity. The best way to manage a network is to cover 
each of the above five areas efficiently. 

The primary goal of network management is to provide the authority with details 
about the health of the network so that performance of the network does not suffer. 
Another goal is to convey information regarding faults like link outages, if any. To aid 
in this task, network protocols are used so that the process of network management is 
automated (ie. run by computers) as much as possible. 

There are many protocols available. The two mainstream protocols are SNMP (Sim- 
ple Network Management Protocol) and CMIP (Common Management Information 
Protocol). Generally, SNMP works under the TCP/IP (Transport Control Protocol/ 
Internet Protocol) communication stack and CMIP works under the OSI (Open Sys- 
tems Interconnection) communication stack. 

1.3 History of Internet Management 

Initial effort towards this started with a straightforward protocol termed as Simple 
Gateway Monitoring Protocol (SGMP). It received quite a good response. A second 
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effort began as a research project which was termed as High-level Entity Management 
Systems (HEMS). Although this had some novel concepts, never saw the light of day 
outside its development sites. 

CMIP (Common Management Information Protocol) [roseQl] was recommended 
and standardized by ISO (International Organization for standardization) for networks 
based on the OSI (Open System Interconnection) suite of protocols. CMIP was inter- 
faced with TCP/IP to manage TCP/IP based networks and this was termed as CMIP 
over TCP (CMOT). CMIP and CMOT were complex protocols', hence CMOT did not 
became popular for n’CP/IP based networks. SNMP (Simple Network Management 
Protocol) was released as successor of SGMP for TCP/IP based internets. CMIP re- 
mained as the management protocol for OSI based internets. CMIP is described briefly 
in sec 2.4.3. 

In 1993 SNMP version 2 was released which addressed many shortcomings of the 
first version like privacy of rlata and authentication of user. A brief overview of this 
is given in sec 2.4.2. In contrast to centralized management, distributed management 
framework has also been proposed which seems to be the answer to management of 
large sized networks [INM4]. 

Some of the teams that are currently working in this field are Columbia Univer- 
sity (DCC Lab), Munich Network Management Team, University of Geneva (Manage- 
ment of Distributed Applications using DMT), TU Delft (Data Network Performance 
analysis Project at Delft University of Technology), TU Wien (A concept and imple- 
mentation of Hierarchical Distributed Network Management) 


1.4 Objective of the Thesis 

The implementation of SNMP was first tried in IIT, Kanpur by Bapat [bapat92] in 
his M. Tech thesis work. He studied the ISODE code of SNMP and configured it for 
potential use on the campus network. Next was Barari [1>arari93] who in his work, 
developed a simple SNMP manager with basic functionalities. Bansal [bansal94] came 
up with a full fledged SNMP manager and developed a proxy agent for managing hosts 
without SNMP agents. He also developed a user interface on a vtlOO terminal. T.S.Rao 
has developed an SNMP manager for wide area networks. 

The user interface developed by Bansal was limited in its capabilities as it was 
implemented using “curses” library functions, hence it was proposed to enhance the 
user interface using MS-Windows and transfer the manager to a less expensive system. 
Thus the objectives of this thesis were to cover above proposals which can be summa- 
rized as below. 

(1) porting of Bansal’s work to Linux environment, 

(2) implementation of SNMP manager in MS-Windows environment, 

(3) providing a window baaed man-machine interface for displaying the status of the 
network, and 

(4) querying the MIB values from SNMP agents. 


^http://www.undergrad.math.uwaterloo.ca/'tkvallil/ snmp.html 
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Some of the terms used above will be explained in later chapters along with the context 
in which they are used. 


1.5 Organisation of the Thesis 

Chapter 1 introduces the network management and discusses the objective. Chapter 2 
provides a brief description of the management issues and protocols. Chapter 3 gives 
a brief ovcuview of the Management Fiamework used in implementation. Chapter 
4 discusses in detail the implementation of the Network Manager and Proxy agent. 
Chapter 5 concludes the work and discusses the future aspects. 

Appendices are provided in the end for quick references. A glossary of some impor- 
tant terms is also provided. 



Chapter 2 

MANAGEMENT ISSUES AND 
PROTOCOLS 


There are .several is.su(!.s aiul a.specf..s pertaining to network inanageincnt like what 
information a i)rotocol mu.st convey, whether a network management jn-otocol is to 
be built upon existing layers or is to be independent of it, etc. Some of these issues 
are discu.ssed in this chapter. Various kind.s of tochnicpics were tried out to somehow 
manage networks in view of these issues. These, in the course of lime, i)aved the way 
for more documented and standardized management protocols. In this chapter a briei 
overview of .some of the.se protocols and techniejues is presented. 


2.1 Management Issues 

The issues which need to be ad<lrcsscd in network management can be broadly classifiei 
into the following three categories 
Functional Issues 

This concerns the definition of management functions. The information 
manipulated by a protocol can be diveded into three classes [dallasSS]. First 
i.s protocol information, encotnpa.ssing all variable relaUxl to th(^ operation 
of the protocol like sump objects in MIB-2 [McCloOlj. Second is report 
information which is related to the history of the entity like traflic statistics, 
.systc'.m up time, etc. Third is (uivinmment information which <k'.scribcH the 
particular context of the protocol entity like addresses, routing tables, etc. 

Integration Issues 

This specifies that inanagement functions should be an integral juirt of 
the protocol layering [fiet95, dallas88]. That is they use the protocol suite 
operating in the .system. For example SNMP ,which manages TCP/IP 
networks, uses UDP/IP which forms a part of TCP/IP protocol suite itself. 


Protocol Issues 
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This gives tlie rules for iutenictioii between management entities. This 
is similar to the rules for intiiraction between peer layers of a protocol on 
(lifRucmt machines [<lallas88]. For exatnple when using SNMP (sec. 3.3), the 
message has to use certain variables and is to be coded using ASN.l (Ab- 
stract Syntax Notation One) encoding [harariOS]. 


2.2 Management Functions 

The network management has to achieve some objectives regarding its functionality. A 
management protocol should be able to provide these. The five complementary aspects 
of the management [rose91, dallas88] are 

Configuration Management which is the set of functions that identify, e.xcrcise 
control over, collect data from and provide data to manage resources for the 
purpose; of supporting contimions operation of cominunication services. Dynamic 
updating of the configuration needs to be accomplished periodically to ensure the 
configuration is known. 

Performance Management which is the sot of functions that control and analyze 
throughput and error rate of the network. Performance is a key concern to most 
MIS (management of information system) support people. Although it is high 
on the list, it is considered difficult to be factual about some LAN performance 
issues. 

Fault Management which is the set of functions responsible for detecting, isolating, 
and controlling abnormal network behaviour such as excessive hue outages. Most 
systems poll the managed objects, search for error conditions and illustrate the 
problem in either a graphic format or a textual message. Fault management deals 
most commonly with (wents and traps as they occur on the network. 

Accounting Management which is the set of functions responsible for collecting 
and processing data related to resource consumption in the network. 

Security Management which is responsible for controlling access to network re- i 
sources through the use of authentication techniques and authorization policies. 
However, most network management applications address only security applica- i 
ble to network hardware such as someone logging into a router or bridge. 


2.3 Management Techniques 

In this section, some of the management techniques [fiet95, roseOl] which are used, arej 
described briefly. These t(x:hui(iues range from simple ‘sending an echo message’ to thd 
more complex management by delegation paradigm. j 
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2.3.1 Ad Hoc Management 

Ad Hoc Management is liased on the fact that it is possible to troubleshoot connectivity 
problems in a network with the help of functionalities provided by ICMP (Internet 
Control Message Packet) [see Sec 3.6]. These mechanisms are the lowest common 
denominators available. Ping and Ti'aceroute arc two such mechanisms. 

The packet internet groper (ping) sends an ICMP echo request packet to an IP 
address and waits for reply. As implementation of ICMP is mandatory for network 
devices supporting TCP/IP and it provides a crude means of testing connectivity. 
Although it gives us round trip time and percentage loss, it cannot report on the 
general health of the network. 

Traceroute sends a series of probe packets using UDP to an IP address. These 
are sent with monotonically increasing values of time to live (TTL). For each TTL 
value, a fixed number of packets are sent. This process continues until an ICMP port 
unreachable packet is received or some threshold is reached. Its elegance is lost as it is 
not entirely a foolproof operation. 

2.3.2 Passive Management 

In case of Ad Hoc Management, traffic (packets) is introduced into the network. How- 
ever management can simply be done by examining the traflBc generated by the trans- 
port protocol which is being managed. This is done by a device called packet moni- 
tor [fiet95]. This approach is called passive management and it relies on capture and 
analysis. However, this technique lacks depth and does not give enough information. 

2.3.3 Centralized and Distributed Management 

Current management systems pursue a platform-centred paradigm, where agents mon- 
itor the system and collect data, which can be accessed by applications via manage- 
ment protocols. This centralized paradigm can be contrasted with a decentralized 
paradigm [INM4] in which some or all intelligence and control is distributed among the 
network entities. 

Centralized SNMP management (see sec 3.3) 

The centralized SNMP paradigm evolved for several reasons. First, the most essential 
functions of network management are well related in this paradigm. Agents arc not 
capable of performing self-management when global knowledge is required. Second, all 
network entities need to be managed through a common interface. Unfortunately, in 
many cases this strategy does not allow for data to be processed where and when it is 
most efficient to do so. The rapid growth in the size of networks has also brought into 
question the scalability of any centralized model. 

Decentralized Management by Delegation 
Maiiagern<!iit by Delegation (MDD) utilizes a decentralized paradigm that takes advan- 
tage of the increased computational power in network agents and decreases pressure on 
centralized Network Management Stations (NMS) (sec 3.2) and network bandwidth^ 
MBD supports both temporal distribution and spatial distribution. In this paradigm 
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agents that are capable of performing sophisticated management functions locally can 
take computing pressure off of centralized NMSs, and reduce the network overhead of 
management messag<!s. In MBD, instead of moving data from the agent to the NMS, 
where it is processed by applications, the application is moved to the agents where 
they are delegated to a process. Thus, management responsibilities can be shifted to 
the devices themselves when needed. 

Decentralized management makes sense for those types of management applications 
that require or can take advantage of spatial distribution. Decentralization also allows 
one to more effectively monitor a network as pcirformance changes over the time. 


2.4 Management Protocols 

As stated earlier, there are two major protocols in this field. They are SNMP for 
TCP/IP based networks and CMIP for OSI biiscd networks. These major protocols’ 
features are explained briefly. 

2.4.1 SNMP 

SNMP was designed in mid 1980’s as an answer to the communication problems be- 
tween different types of networks. It is a second generation protocol as it is developed 
from SGMP. 

The way it works is very simple. It exchanges network information through mes- 
sages, called PDU’s (Protocol Data Unit). From a high-level perspective, the message 
(PDU) can be looked as an object that contains variables that have both titles and 
values. It is cxi)lained in detail in Chapter 3. 

2.4.2 SNMPv2 

Though popular, SNMP' is not a perfect network management protocol. The first 
deficiency is that it has large security gaps that can give network intruders access to 
the information carried along the network. 

The latest version of SNMP, called SNMPv2 has added some security mechanisms that 
help combat three largest security problems - privacy of the data, authentication of 
user and access control. Also, manager to manager communication tools are available 
under SNMPv2 making it more suitable for large networks. Two new PDU’s are added 
that are used to manipulate tabled objects. 

2.4.3 CMIP 

CMIP'^ was designed to build on SNMP by making up for SNMP’s shortcomings and' 
becoming a bigger, more detailed network manager. Its basic design is similar to 

^http: / / webl .digital.net/'snmx/SNMXJSNMP .overview.html 
^http: / /www.undergrad.math.uwaterloo.ca/'tkvalil/work.htm 
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SNMP, whoroljy PDU’s arc employed ;is variables to monil.or a network. CMIP however 
contains 11 types of PDU’s (compared to SNMP’s five). 

In CMIP, the variables arc seen as very complex and sophisticated data structures, 
with many i)roperties. These include : 

1) Variable attributes: which represent the variables characteristics (its data type, 
whether it is writable). 

2) Variable behaviours: what actions of that variable can be triggered. 

3) Notifications: the variable generates an event report whenever a specified event 
occurs (eg. a terminal shutdown would cause a variable notification event. 

As a comparison, SNMP employs only variable properties one and three from above. 

The biggest feature of the CMIP protocol is that its variables not only relay infor- 
mation to and from the terminal (as in SNMP), but they can also be used to perform 
tasks that would be impossible under SNMP. For instance, if a terminal on a network 
cannot reach its fileserver in a predetermined amount of time. Then CMIP can notify 
the appropriate personnel of the event. Another advantage to the CMIP approach 
is that it addresses many of the shortcomings of SNMP. For instance, it 1ms built in 
security management devices that support authorization, access control, and security 
logs. 

One of the reasons why CMIP has not been commercially popular is due to the fact 
that it runs under the Open Systems Interconnection (OSI) network communication 
protocol. OSI performs almost all of the communications functions that TCP/IP does 
plus many more. It is thus thought to be a much more complete network communica- 
tion package. However, with this increased completeness comes a massive increase in 
system resources that OSI takes to implement. 


2.5 Summary 

Management issues which influence the management protocol as well as architecture 
can be broadly classified as functional issues, integration issues, and protocol issues. 
The main functions of network management are configuration management, perfor- 
mance management, fault management, account management and security manage- 
ment. The management techniques are used so as to perform these functions effectively 
keeping in view, the issues. These range from Ad Hoc management to decentralized 
Management by Delegation. The two major protocols, which are used, are SNMP and 
CMIP. A short description of them were provided and their respective advantages and 
disadvantages summarized. In the next chapter, the management framework used in 
the implementation is described along with the architectural model and protocol. 



Chapter 3 

MANAGEMENT FRAMEWORK 


3.1 Introduction 

A irmnageinent framework is defined by the architectural model and the set of protocols 
used. For example, in this implementation, the management model consists of the PC 
(on which the SNMP manager is implemented), several UNIX machines (acting as 
hosts) and a Linux machine (acting as a proxy agent). In this chapter, a description of 
management model and protocol used in the implementation is given. The description 
of SNMP agent, manager and proxy agent is also provided. 

3.2 Management Architectural Model 

A simple management architectural model [ro.se91] is a collection of managed nodes 
with an agent, managed nodes without an agent and one or more network management 
stations. A managed node may be a host system, gateway etc. The fundamental 
axiom which influences the design of the management systems is ''The impact of adding 
network management to managed nodes must he minimal, reflecting a lowest common 
denominator" 

3.2.1 Network Management Station (NMS) 

A network management station is a host system which is running a network manage- ! 
merit protocol (sec. 3.3) and a network management application. A network manage- : 
ment application is developed in this thesis work and is explained in Chapter 4. 

The network management station is responsible for management functions like traf-, 
fic management, fault location, etc. Moreover, it runs management applications so that 
it is able to perform these management functions effectively and provides a user inter- 
face to the authority to help get a overall picture of the network performance. 




Figure 3.2: Components of a managed node 


3.2.2 Managed Node 

A managed node (MN) refers to a host system such as a workstation, gateway system 
or media device such as a bridge. 

A managed node may or may not have an agent. An agent is a network manage- 
ment software which collects data from the node and provides them to the network 
management stations when asked by them. The concept of an agent is discussed in: 
sec. 3.4 . 

The commonality of all managed nodes is that they all have some network capabil- 
ity. A managed node having an agent can be visualized as containing following three 
essential components 

1. Useful protocols which perform user defined functions. 
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2. Managcnicnt protcxtol whic.li poniiits monitoring and control of the; managed 
nodes. 

3. Management instrumentation which interacts with the implementation of the 
managed node in order to achieve monitoring and control. 

A managed node without an agent supports only the first option. It may have a 
management protocol which is different from the one being used by NMS. Therefore, 
to manage it, the need of a proxy agent arises. The proxy agent receives the messages 
from NMS and translates tlunn to messag(‘s which the manage<l node can understand 
and respond to. The concept of proxy management was described in sec. 2.3 and that 
of the proxy ag(;nt is described in sec. 3.C. 


3.3 Management Protocol 

A network management [protocol is one which is used by the NMS and the nodes to 
exchange management information. There arc several forms which this protocol might 
take. For example it may be used to exchange “programs” or “commands” in some 
paradigm. 

In the Internet Standard Management Framework, a “fetch-store” paradigm [comer94] 
is used. This means that the node is monitored and controlled by several variables 
which an NMS can read or change. Thus, the management protocol needs to be sup- 
ported by the definition and declaration of various variables which it will use. Also, a 
standard nee<ls to be established for their declaration and definition as well as to limit 
their number. 

The current management framework for TCP/IP networks btised on SNMPvl, 
which was given a stable foundation on May 1991, consists of four RFCs dealing with 
the above mentioned issues. These four RFCs are briefly discussed below. 

RFC 1155 : Structure and Identification of Management Information for TCP/IP 
based networks [McCloQO]. 

This describes the common structures and identification scheme for the 
definition of management information used in managing TCP/IP based 
networks. The descriptions of an object information model for network 
management along with the set of generic types used to describe manage- 
ment information is included. An object is defined as a variable having a 
name, syntax, and valid set of operations that can bo performed on them. 

TIk; forrruil descrii)tionH of the structure are given using Abstrac.t Syntax 
Notation One (ASN.l) [barari93]. This RFC is mainly concerned with the 
organisational concerns of the variables and the administrative policy fol- 
lowed regarding assigning of names to objects. Definitions given in this 
RFC are provided in Appendix C. 

RFC 1213 : Management Information Base for Network management for TCP/II 
based networks. [McClo91] 




Figure 3.3: MIB tree 
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Figure 3.4: Lexical ordering of MIB objects 


This RFC lists over 100 objects that hold the configuration, status and 
statistical information that are most needed in order to manage a system 
that operates in TCP/IP. These variables are kept independent of the net- 
work inanagoment protocol so as to allow vendors to incorporate software 
in their products that gather statistics without worrying about the protocol 
to be u.s<!<l. I'he objects are arranged in the following groups 


SysUun 

7 ()bj<!cts 

lnt<irfa('.(‘ 

23 ol)jects 

Address translation table 

3 objects 

IP 

38 objects 

ICMP 

26 objects 

TCP 

19 objects 

UDP 

7 objects 

EGP 

18 objects 

Transmission 

0 objects 

SNMP 

30 objects 


ASN.l defines a lexicographical ordering on the objects in the MIB. This orderin| 
allows the managers to ask the agent for the set of currently available variables and t( 
search the table without knowing the size. Two names are lexically equal if they havi 
identical object identifiers. An example of lexical threading is shown in fig. 3.4. : 

RFC 1157 : A Simple Network Management Protocol (SNMP) [caseQO] 

This RFC defines the messages that can be exchanged between a man- 
agement station and a managed node to retrieve (get or get-next) or alter 
(set) variables values.- Their operation is shown in the fig. 3.7. Thus, the 
number of essential management functions arc limited and the introduction ! 
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!5i6 32 


source port 

destination port 

length 

checksum 


serialized SNMP message 


Figure 3.5: UDP packet format 


of imperative commands into the protocol is avoided. The trap messages, 
sent by a system whose status is changing in a serious way are defined in 
this RFC. Moreover, it deals with the details of message format and commu- 
nication protocol specification. The PDU format of various messages are 
given in Appendix D. This RFC deals with the communication protocol 
specification which is <li.scusscd in the next section. 

RFC 1212 ; Concise MIB definitions [mibOl] 

This RFC improves on the definition techniques given in RFC 1155. 


3.3.1 Transport Services 


SNMP is meant to be transport protocol independent. There arc several mappings 
defined. All the mappings have one thing in common. Instances of the SNMP message 
data type are transmitted through a process termed as serialization. This allows an 
arbitrary data structure to be encoded as a sequence of octets for sending. When 
the octets are received, they are converted back to a data structure with identical 
semantics. Thus, there is unambiguous one to one mapping between the ASN.l data 
structure (Udined above and string of bytes. All implementations of SNMP are required 
to accept messages which are serialized in 484 octets or less. Ihere is no requirement 


on sending SNMP entities. 

Mapping onto UDP is [meferred. A sending SNMP entity serializes an SNMP 
message and sends it as a single UDP datagram to the transport address of the receiving 
SNMP entity. The UDP packet format is shown in the fig. 3.5. 

The transport address consists of an IP address and a UDP port. All SNMP agents 
listen on UDP port 161. If a message contains a trap, the receiving SNMP process 
listens on port 162. By convention, all responses are sent with the source/destinatior 
ports swapped from the corresponding request. Thus, a get-request sent from port 1001 
will have the corresponding get-response sent back at port 1001 of the same machine 
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Figure 3.G: The flow of an SNMP rcq\iest, through a server 

3.4 SNMP Agent and Manager 

An SNMP agent (also called server) [comer94] is a software on the managed node 
which implements the internet management framework. It accepts an incoming request, 
performs the specified operation and returns a response. The agent repeatedly waits 
for an incoming request. On receiving a request, the agent first parses the message 
and translates it to an internal form. It then maps the MIB variable specification to 
the local data it(!in that stores the needed information and performs the fetch or store 
operation. After that it tran.slate.s the reply from internal form to external form, and 
sends back to the address from which the request came. 

An SNMP manag(‘r is a software rtmning on management stations. The manager 
forms a reciuest message, sends it to the agent and then waits for the reply. The man- 
ager also f.ranslates the message from internal form to external form before sending, 
and external form to internal form after receiving. On receiving the reply, it veri- 
fies if the response matches the request. It also implements timeout and if needed, 
retransmission. 

3.5 Protocol interactions 

SNMP is an asynchronous request/response protocol whicli means an SNMP entity 
need not wait after sending message. It can continue with sending other messages or do 
other activities. This is due to the fact that an unreliable datagram transport protocol 
is used for SNMP. Due to this reason, messages can be lost and it is the responsibility 
of the application to do retransmission. The four basic protocol interactions are shown 
in fig 3.7. Of those, get and get-next is implemented for agents and set for proxy agen) 
in this implementation. : 
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Figtire 3.8: ICMP packet format 

3.6 Proxy Agent 

Sonw of tlif hosts to lx; iiitintigctl may not have an SNMP agent or they may bo media- 
spec.ifu: ix)sfs. A ntdwork manager manages these hosts via a proxy-agent. A proxy 
tigeni may tran.shiU* tlx; protocol or jtisl send messages to get management data. In 
tliis implcnientaf ion, i)rttxy tigcnt n.ses a ping snhrontine to get the status of the host 
irrespect.ive of tlu; fact \vht;th(;r an SNMI’ agent is running on it or not. The ping 
subroutine n.ses IClMi' echo rixinest packets. A brief description of the same follows. 

Int(!rnet C’ontrol Mt>.ssage Protocol (ICMP) is a protocol at the IP level, giving a low 
level f(;edha(’k about the general health of the IP level. ICMP uses delivery services of 
IP. If the protocol field of an IP datagram is 1, the user data contained in the datagram 
is an ICMP packet. The first 32 bits contains the same three fields for all messages. 
The three fields are 

1. Tyj)e : Identifies which control message is being sent. 

2. Ckxh* : hUmtifies a basic paramet(‘r for the control message. 

3. ll<;ader Checksum : A one’s complement arithmetic sum computed over the entire 
ICMP pack(!t. 

' Som<; of th<; control m(!ssages supported by ICMP are 

1. Destination Unreachable : Local IP received a datagram which it cannot route. 

2. Time Exceeded : Time to live field in IP header expired. 

3. Parameter Problem : Erroneous IP header. 

4. Sourc(; Quench : To report a network device discarding datagrams due to lack of 
rcisources. 

5. Redirect : Originated by the gateway to report another gateway closer to the 
destination IP address. 

6. Echo/Echo R(;ply : To test reachability of an IP address, an echo message is sent 
and the receiving entity sends an echo reply message in return. 

7. Tiimistainp/Timestamp Reply : To sami)lc the delay in the network between two 
network devices. 
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3.7 Summary 

The tnanagcmi'nt franii'work for SNMP consists of four RFCs. These are RFC 1155, 
RFC’ 1157, RFC 1212 and HhC 121.3. These are discussed briefly in this chapter. The 
present implementation fully conforms to the said framework. The management model 
is also bri(dly des<Til>e<i. 'Phe conummication between SNMP agents and manager 
is done via connect ionless transjiort protocol such as UDP, so as not to burden the 
netw’ork with management traffic. The SNMP agent on receiving a request decodes it 
and puts in the require<l %’a!ues and scnids it back to the manager after decoding. The 
functions done by tln^ agent in this procedure are also discussed. 

I’hough not part of the framework, proxy management is discussed; this is because 
the imjjh'imMitation u.s(*s this and it needs to be clearly understood before proceeding 
towards implementation. The next chapter describes the implementation in detail. 



Chapter 4 


IMPLEMENTATION OF THE 
NETWORK MANAGER 


4.1 Introduction 

III this cluiplcr tho imfilementation of an SNMP manager and a proxy agent are dis- 
missed. This inelud(‘S the architeeture of tiie manager and various algorithms which 
are desigiusl for im[ih*mentation. The manager is implemented on MS-Windows envi- 
ronment. 'riiuK, various I’upaliilities of MS-Windows like easy to design graphical user 
int-m hu'cs and network support are fully utilized. The proxy agent is implemented in 
Linux eiiviroumenl. Linux is used for the Hrst time in the ERNET Lab as a dcvclop- 
mmit environment. A brief <h>.Heripl ion of this, is provided in the Appendix B. As a 
part of (lie thesis work, Ban.sal’s SNMP manager and proxy agent on Micro Vax was 
porU'd to Linux. This is tU.senssed hrielly in the next section. 

4.1.1 Porting SNMP manager to Linux 

Bansal {bansal94} implemented an SNMP manager on MicroVax with a good user 
intorfac«‘. lie also developed a proxy agent for polling hosts without an SNMP agent. 
As a part of this tlmsis work, Bansal’s SNMP manager with all its user interface 
capabilities is successfully ported to Linux. The reason behind porting the software to 
Linux is that Linux is fast developing into a popular operating system for PCs. It has 
all the <!apal)iUties of UNIX operating system*. Also since its source code is readily 
available and is for free, it is fast becoming a popular development environment as 
developers can change the operating system to suit their needs. 

In porting the software, the algorithms developed by Bansal were followed and 
programs wore either rewritten or modified. Here, the communication between the 
manager an<l the proxy agent is carried out using socket ajiproach. The major changes 
in tlm implenumtation are changes in the functions for sending and receiving SNMP 
messages from proxy agent and dynamic allocation of memory. These are done as 
the working of “signal” function in Linux is only partly supported and the amount 


’ http:/ /suii.site.unc.wIii/piib/Hnux 
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Wimltnvs 3. 1 


all hosts 


Finui<‘ *!.I; Block diagniia of iinplonionlation 

of memory allocated to a process is limited. As far as the proxy agent is concerned, 
in ad<!ition to sorting ont, the above problems, the ping routine is modified to run on 
Linux. 'I'he changes are nei'dcHi because ICMP options arc different and some of them 
an; not support«’d in Linux and structures and variable names as defined in header files 
are diffen'iii. 

'I'he iK’xt section <iiHcusses architecture of tlie implementation of SNMP manager 
on Windows envinunnent. 


4.2 Architecture 

4.2.1 Introduction 

This se(;tion <!Xplains th<^ archit<!cturc of the management framework used in the imple- 
mentation of ! h<! jKftwork manager with iisxu interface on MS-Windows. This includes 
algorithms u.s<’<i and the arclut(u;ture of the network manager and the proxy agent. 
Whereas tin? network managcir resides on Windows 3.1 environment, the proxy agent 
runs on ‘1.3 BHD compatihh! Linux Hy.stem. The proxy agent is used to monitor the 
staUis of all hosts. I’he network manager can poll tlirectly a host which is running 
an SNMP agent for any MID value. The block diagram representation of the network 
manager along with proxy ag<mt and SNMP agents is shown in fig. 4.1 . The figure 
also shows th<! environments on which these are implemented. 

The. luitwork manager performs two functions. First it polls the proxy agent to 
get th<; status of hosts in the network. The proxy agent sends an ICMP echo request 
packet to the host ajul waits fiur reply. Once it receives the status of the host, the 
proxy ag(;nt forms an BNMP reply and sends back to the manager. Secondly, it polls 
any host which is running an SNMP agent for MIB values. This is done by sending 
an SNMP g<;t or g( 5 t-n(!xt request. The user interface shows the current status of the 
network. Th(i algorithms for network manager and proxy agent arc shown in the figure. 







In tliis ijnpli'im'iil ut i«>u iiitciprtx'css conniiuniriilion hotwoon different environments is 
list'd. 'This done nsin);!, winsoek library functions [inartin92]. 


4.2.2 Network Klanager 

I’he niiina^er has two functions as stated above. In both the cases, ie. polling the 
proxy agent and (juerying HNMP agents for MIB values, it converts a C structure 
into ASN.I data types. Using Basic Encoding Rules (BER), it encodes the ASN.l 
data type for sending it to the j)roxy agent or the SNMP agent. For sending the 
nies.sagt‘ to the proxy agiuit and difh’rent hosts from from the manager, the program 
uses “winsoi’k” (inartinD’i]. Also, the graidiical capabilities of windows are made use of, 
like drawing lines, writing ti'Xt with different bai-kground colours. The message driven 
program confrui of windows is utilized fully in the program. The windows own memory 
allocation routines are u.sed in the |»rognimming. Thus, windows allocate memory to 
the |)roc<'.ss ami memory management of windows is made use of fcongcr94]. 

'I'he manager dt>es tht! following things before displaying the iirterface(fig. 4.2). 

1. It <‘all.s “\VSA.Startu{)()'’ which allows the application to specify the version num- 
ber and to ref riev(‘ the tletails of the implementation. 

2. It reud.s the configuration file “coufig.txt” and fills up the agent structure for 
all the hosts. The configuration file contains three fields namely, host name, IP 
address and wlu'tlu'r its a SNMl* agent or not. The last field is an integer where 
“one” denotes an SNMi* agent ami “w'ro” specifies its absence. The number of 
Imst.s is obtaijied by eai<*ii!ating tlie number of structures successfully filled. 

3. It loads the IP address of the machine on which it hs running. This is different 
from IJNiX implementation where with the help of “getkcalhOvSt()” one can get 
fix' loeal host name. 'Phis funtdion is not supported on the Winsoek used. The 
IP a<ldre.ss of the i>rt»xy agent is loaded into a string. 

4. Tire socket for communication with the proxy agent is opened and bound with 
IP address. 'The port nmnlier u.sed is 1000. 

5. To provirle non-biocking operation of sockets, “WSAAsyncSelect()” is used which 
Kp<‘cifi(’s that in case any incoming data on that socket, the “WM_USER2” win- 
dow message rotitine should be processed. 

“WSAAsyncSekictO” Imlps in the non-blocking operation of the socket. The program 
can continue with otinu prociissing while waiting for packets to be received at the 
receiver port. I'his saves a lot of processing time which w<is previously getting lost in 
waiting. 
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Figure 4.2: P'low chart of the manager 
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Figure 4.3: Flow chart of manager(contd.) 
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For polling tho proxy agoiit, the manager does the follo\ving(fig 4.3) 

1. H(‘S(“t.s t.he counter t.o '/('ro and start proce.ssing “WM.USERl” window message 
routine. 

2. The manager checks tin; value of counter, loads the IP address of the machine, 
to whicli ICMI’ echo packet is to he sent, in the “set value” puts the pdu type 
“SET” and forms the SNMP packet with the coder.snmp() function. 

3. Aft(*r s(*nding tin; pack{;t to proxy ag(;nt it sots a timer. If reply is not received 
from i)roxy agent within the timeout period, the program terminates. 

4. Tin’ })a<'la*t returned Ijy tin; proxy agent is decoded. The value in the var bind 
stimctun; si>ecifies tin; status of the host to which ICMP echo packets were sent. 
Z(;ro si)t;(ufies status down and One specifies status up. 

This proc(;dur(; is continued till all the hosts are polled in this manner. After this 
the display is shown with the recent status of hosts. The polling of hosts via proxy 
agent is repeated after every 5 minutes in the present implementation. 

The manager can also send the SNMP request to hosts running SNMP agent. 
Another capability of windows, “Dialog Box”, is utilized here. It provides an easy way 
for inputing data to a program. The manager makes an SNMP packet, sends to the 
host and waits for the reply, this it does in the following stei)s (fig. 4.4). 

1. The; manager takes the host name, sub-oid and i)dii type from dialog box. 

2. Op(;ns anoth(;r sock(;t with port number 1001. Then it codes the message and 
.s<;tjds it to the agent on UDP port 161. 

3. The same non-blocking operation is used and if reply comes within timeout pe- 
riod, it is deemded. The value is shown in a “message box”. 

4. The socket is closed with “closesocket()” call. 

The above di.scussion lists the working of the manager. In this discussion the term 
manag<;r apples to the. process running on the network manager end. The flow charts 
are provided showing the program flow. In the next section user interface is explained. 

4.2.3 User Interface 

The user interface is developed to provide user friendly controls and easy interaction 
with the program. The interfaces arc shown in fig. 4.5 and fig. 4.6. 

The display begins with a message saying “KINDLY WAIT” . At this moment one 
can cither start polling the proxy agent or else can send a request to an SNMP agent. 
To start the polling, tlie user clicks the menu item “Start”. After the polling is over, a 
message box appears on the screen with a message “polling over” and screen is refreshed 
with a display showing status of hosts in the network. Any error occurred during polling 
is shown via message box and if proxy agent is not responding the program terminates. 
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1'his is doin', St) as not. to hang np the prografn before one realizes that the fault lies 
with the proxy agent. 


I lit' indi vidiiul displays foi' I'jLNLI , CICNET and CSENET can be got by clicking 
resi)eft ive menu itt-ins. In t his display, the respective IP addresses of the hosts displayed 
are shown along with. 'I'he inmn item “Back” brings the display back to the original 


one. 


it) ,s(‘ntl an SNMP rt'tpmst to a host, one has to click menu item “Dial”. This opens 
a dialog box. 'i’ht! dialog i)ox provides a user friendly way of sending an SNMP request. 
The samph' values art; shown along with it for the convenience of the user. 

The cur.sor position can ho moved either by pressing “Tab” key or else clicking left 
mouse button at each of the item. After giving the value of sub-oid, specifying host 
and the recpiest pdu type, the “DONE” button is clicked. At this an SNMP message 
is st'ni and the reply from the host is shown in a message box. The “SET” operation 
is not supporteil by the manager. 

The polling of the hosts via proxy agent is done after a regular interval hence the 
screen is refreshed from time to time. The “Dial” is disabled during the period when 
proxy agent is being polled. When user clicks “Exit” menu item, the implementation 
frees all the memory and closes the socket which was opened for communication with 
proxy agent. Then manager i.ssues a “WSACleanup()” to terminate the use of windows 
sockets DLL. 


In this implementation, the dynamic allocation of memory is done and the memory 
is deallocated wlu'iievi'r [)o.ssihle. I'his is done to keep the memory requirement of the 
program to the minimum. 


4.2.4 Proxy Agent 

The status of the hosts is found out via proxy agent which uses ICMP echo messages. 
This was developetl by Bansal [hansal94] by modifying “ping” routine. It was further 
modifiei! to run on Linux. The algorithm followed is shown in fig. 4.7 . 

The program opens j>ort 1000 and waits for requests from the manager. Once the 
proxy agent receives an SNMP request, it decodes the packet and finds out the host IP 
a(l(Ire.ss from the value fiehl of the suh-oid “1.1.0”. The proxy agent then sends ICMP 
echo recpiests packets to this host. A modified version of “ping” routine is used for this 
purpose. If the reply is received within the timeout period, the status of the particular 
host is “UP” else it is “DOWN”. After this reply is sent with recent status in the value 
field of the sub-oid. The proxy agent then goes into the waiting mode. 


4.3 User Defined Structures and Functions 

In this section, the various structures and functions used in the program are described 
below. The coding/<!nco<ling functions used by the manager and the proxy agent are 
developeil by Barari [barari93]. 
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4.3.1 ASN.l Encoding/Dccociing Structures 

A «!t',scii[)l i»r .slnicliin* is liscd to store? all infonnatioa about one SNMP lues- 

sage!. 

struct rc(j.(lcsc { 

u.cliar n‘(}typ<'; /* rcciuest type */ 

u_char rc<iid[l{)]; /* request descriptor */ 

int n*qi(ilen; /* length of identifier */ 

u .char err-stat; /* error status */ 

uj-har crr.idx; (* error index */ 

int err.,statq)os; /* place of err stat */ 

/* in the ine.ssage */ 

int err.i(ix..pos; /* place of err _idx */ 

int pdnlype.pos; /* position of pdu type */ 

struct snheniry *hiiuilf; /* beginning of binding list */ 
struct snluMiirv ‘ bindh?; /* end of binding list */ 

I; 

Each siihentry structure stores information about one variable binding in the mes- 
sage. The list is doubly linked to form a queue of the variable bindings, 
struct snhentry ( 

stnud oid sh.oid; j* object id in the internal form*/ 

strtict snval sb.val; /* value of the object */ 

int sb.alslen; /* length of the ASN.l string */ 

struct snhentry *sh.next; /* next node in the list */ 
st,ni<-t stibetitry *sb.prev; /* previous node in the list */ 

Th(j structure “oid" stor(*s the sub object identifiers, 
struct oid { 

int id{32]; /* array of sub-idoutifiers */ 
int hilt; /* length of this object id */ 

}; 

The structure “snval” stores the value of the object identifier, 
struct snval { 

u.ehar .sv_ty[><?; /* variable typo */ 
union { 

Io!ig svJnt; /* variable is one of integer */ 

/* counter, gauge, timeticks */ 

struct { 

char *sv.str; /* string’s contents */ 
int KV Jen; /* string’s lengLli */ 

} sv_str; 

struct oid sv-oid; /* variable is an OID */ 

IPaddr svjpaddr; /* variable is an IP address */ 

} sv.val; 



}: 

IP.-uidr is t as 
typt'ili'f’ u.iiiar IPaddi j l); 
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4.3.2 Agent Structure 


For ('ach aA«'ut thoro is a structure “agent” which stores information (based on entries 
in the “coidig.txt” fi!«*) pertaining to it. 
struct agent { 


char *naine; j * domain name of the host */ 
<-har Mpadcir; /* ii> ad<lr<‘SK in a.b.c.(i form */ 
int status; /* status of tlui Ijost */ 
iul a. sump; /* whether it runs SNMP agent */ 


}; 

Th(U'<^ is a global array of pointers to the structure 
agent.. 


“agent”, each array entry for each 


4.3.3 Functions in the Program 

The various functions used by the manager and the proxy agent are discussed below. 

File Read Functions 
conligO 

I’his function n'.uls each host entry from “config.txt” file. It allocates memory to the 
agent structjire atid fills it with entries for a host in the file. It terminates the program 
if any tn ror oc<?urs. 

Display Function 
DrawLine() 

This function draws a line Ixitween two points whose X and Y coordinates are given. 
WriteText() 

This function writes the sp(^ci^ied text at the specified position with the background 
black or white jis given l)y the variable “col”. If it is “0”, text is white on black back- 
ground and it is “1", it is otherwise. 

Set{) 

This function gives X and Y coordinates of host display depending upon its IP ad- 
dresses’ tenth character which is different for different sub-nets. 

SetRout() 

This function gives X and Y coordinates of router display depending upon its IP ad- 
dresses’ fourteenth character. 
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du*ck() 

'I’liis fiinrfiDn du'cks whrtlirr u SNMP 
a to that, oili’ct. 


aj^tnit is running on t.hn host or not and displays 


Memory Allocation Ftmctious 
acalloc() 

This funcfion aliocati's spcciliod nuinhor of bytes from windows local heap and locks 
it. 

afret'O 

This fiHu fion fn*cs the memory ailoeated by “acallocO”, 

Encoding/ Decotling Functions 
alreadien{) 

Tins function reads and reltini.s the length of an ASN.l encoded object type. It also 
returns the length of tln^ length fi<dd of an ASN.l encoded object through a pointer 
I)a.s.s«si to it. 

alwritel(‘n() 

This function \vr!t(‘s the length of an object in ASN.l encoded form and returns the 
number of bytes in the en(:ode<l length field. 

alnunlintO 

'Phis function ronverls an ASN.l ennxh'd integer into a internal form. It requires the 
length, in number of byU's, of the value field of the encoded integer as an input and 
the hyU> stream consisting the encoded integer. 

alvvriteint{) 

This function writes the value of the integer in ASN.l encoded form and returns the 
length of the ASN. I (mcodod integer in number of bytes. 

alreadoidO 

This function converts an ASN.l encoded object identifier into internal form. It re- 
moves the fixed prefix ‘T.3.G.1.2.r’ common to all SNMP object ids and then stores 
the rest in the structure “oid”. The length of the object id, the encoded byte stream 
and pointer to the “oid" structure must be passed to it. It fills the “oid” structure and 
returns 1 in case; of no error; else it returns -1. 

alwriteoidO 

This function etjiivtirts obj<!ct itkuitilier into ASN.l encoded form and returns the length 
of the encoded object id<5nlifler in number of bytes. 
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aln‘;i(}v;il| ) 

'Phis functinii reads ih.' value of (he insfniin? “vahto” from ASN.l encoded byte stream 
and St OH'S it into an "siival" stnuHinn !t returns 1 in case no error and -1 in case of 
error. 


alwritevaU) 

Tliis function encodes the value of “value” of an ASN.l variable binding from internal 
structure to byte stream and returns the length of the value in number of bytes. 

sna21>() 

This function converts ASN.l encoded binding into internal form and filling the ele- 
nnuits of the “subentry” structure. In ease of any error -1 is returned. 

.snb2a() 

'Phis functhui converts tin* list of variabh; bindings in internal form in the “snbentry” 
stnictun* to ASN.l huun ajid store hytt' stream in “sb_alstr’’ element in the same stnic- 
turt!. In case of any error - I is returned else 1 is returned. 

sni)arse() 

This function converts tin* ASN.l encoded into internal form, filling the “req_desc” 
structure. In case of any error -I is returned else 1 is returned. 

inksmiipO 

'Phis function makes an ASN.l encothsi SNMP packet from a “req.desc” structure. It 
nd.urus the h'ni'.th of t he pack<'t in nmnlx'r of bytes. 

snmpJVet'O 

This function is tised to frei* any nnunory allocated to a “rc(j.desc” structure. 
snfreebl() 

This function frees any memory allocated to the doubly linked list of ’’snbentry ’s”. 


coder _snmp() 

This function gtjts the type of packet and list of sub-object identifiers. Then fills the 
“req_desc” structure and calls above encoding routines to form an ASN.l encoded 
SNMP message. It returns tlic length of the packet in number of bytes. 

<iecod(u'() 

This function <lecodes an ASN.l encoded SNMP message and fill up a “req_desc 
structure. It returns 0 if there was no error in decoding else returns -1. 

Functions to Show Error Messages 

wsa_crror() 

This function creates and shows a message box indicating the particular error which has 
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()ccur!<'<i in cast* uf wiiisuck «'U'ur.s. 
Last!‘!n-()r() I'uiu'tioji. 


TUo (MTor occurrod is known by calling WSAGct- 


nic!n-orr(>r( ] 

This fuiu-tion <-n‘!it(*s and displays a message box indicating memory fault in case 
windows tanild not allocate inemory to it. 


Function to Send Ping Packet 
semLping-packetO 

This fun<-tion is !ta.sed on user program “ping”. The arguments passed to this function 
are host, address and nnniher of 5>ack<4s to he sent. ICMP echo packets are sent based 
on these arguimmts. Tlie function returns the luimber of reply packets received in the 
response. 


4.4 Summary 

In thi.s chapter iinpUnnt'iitation details inclnding functions used and user defined struc- 
turt's art! tlescribed. I’his chapter aims at clearly specifying the implementation. In 
addition to this, programs art! tiocumented in a way so as the reader can clearly get 
wliat the prt)giani is titnng. “nE;\DME” and “doc” files are provided as online help to 
users and developers both. 'I’lit* next sectitm tonclndcs the work and discusses future 
sftjpe of tilt* work. 



Chapter 5 

CONCLUSION 


'I’ht' primary ahjrct ivt* of this tiiesis was to implement an MS-Windows based network 
inaiiaf’cr wit h user int(*rfaa‘. This was achieved with the implementation of the network 
maiiaj^tM', which shows tht‘ status of local network and also can get MIB values from 
SNMP agents, on Wimlows 3.1 using winsock. The implementation has two parts. 

First tin* network manager program was written by building upon the work on 
implementation (d' BER using ASN.l [barari93]. The present implementation has fol- 
lowing features. 

Polling the status of h{)sts using a remote proxy agent. 

(.Querying MIB vahies from hosts with SNMP agents. 

Displttying stattis of the local network. 

Menu {iriven user int,(‘rfa<’<;. 

The present implenientat.ion is having laoxy agent running on Linux. 

Sec«mdly, proxy agent developed by Bansal [bansal94] Wcis modified to run on 
Limix tmd communicate with the network manager running on MS-Windows. Thus, 
this an example of interprocess communication between processes running on different 
environments. The implementation done can be applied to larger networks as well. 

The source files for the netw^ork manager are stored in “c:“bhar“fine” in the PC 
as w(dl as sjibmitted to the “ERNET Lab” in floppy. The executable file is also stored 
along with and can he run from an icon in the program group “Applications”. The 
source files and executable file (proxy) of the proxy agent are stored in the directory 
“/home/hhar/arch/prox” . 

As a part of this thesis work, the network manager residing on MicroVax was 
succ<‘ssfu!ly ported to Linux. The source files of the ported program are in the directory 
“/Imrne/hhar/arch/mgmt” . 


5.1 Scope for Further Work 


lUil.workH can be managed usiiiK present iiiipleiiiciitatioii with iiiinoi modili- 
cations. proxy agent concept can be modified to get a local manager for loca 
network, which in turn can be polled by a central network manager, thereby reducing 
the .nanag.!.nent tratfle in the network. This concept can be very helpful in managing 
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u lai'iv network as th<’n the munagor ■will be polling a few local proxy managers rather 
than all the hosts. 

riie i)i:ina}',ef ean In* ported to X-windows which has better multiprocessing capa- 
biliiii's than MS-\Vin<it.»ws. This can be a future scope of work. 

Hv modifying the program, MIB values can be polled continually and a local 
tiatal)a.se at the manager end can be maintained for ready reference and analysis. 

Trap is not recogni/.ed by the present implementation. Trap is issued by the agent 
when an exception occurs. The manager can then poll the agent to know about the 
exact status. 

The present implementation, thongh exploiting many features of MS-Windows, does 
not provi<le multiple windows so that each subnet can be viewed simultaneously. This 
can be u<ided to the pre.sent implementation. 

With the enhancements lus suggested, the present implementation can be used for 
couiplefe network management of any network irrespective of the size. 
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Appendix A 
WINSOCK 


'I’iu' WiiulowH Sockets sjx'oification defines a network programming interface for Mi- 
crosoft W'iiiiiows, wliicij is based on the “socket” paradigm as stated in the Berkeley 
Software Distriljution (BSD). It encompjisscs both huniliar Berkeley socket style rou- 
tiiH'S and a set of set of Window-specific extensions designed to allow the programmer 
to take atlvantage of the message driven nature of Windows. 

Network software which conforms to this Windows Sockets specification are considered 
“Windows Sockets Compliant” . Specifically, all Windows Sockets implementations sup- 
pcjrt bot h st.ream and datagram sockets. The Windows Sockets Specification has been 
built itpon tin; B<‘rkeley Sockets programming model which is the standard TCP/IP 
networking. 

'flu* Windows Sockets specification includes about all the Berkeley-style socket rou- 
tines. These includes aa^eptO, hind(), scnd(), rccv(), etc. 

'i’he ma.jtu- Issue in porting applications from a Berkeley sockets environment to a Win- 
dows «>nvironinent is “blocking”; io. invoking a function which does not return until 
ns.so<‘iated operation is completed. The problem arises when the operation takes arbi- 
trarily long tinu! to (!oinpl(!te. However, within a windows sockets implementation, a 
bio<rki!\g operation which cannot be completed immediately is handled as follows. The 
DLL initiat<?s the operation, and then enters a loop in which it dispatches any Windows 
in(^ssag(?s and then chocks for the completion of the Windows Sockets function. Tlius 
message driven operation of windows is utilized. To facilitate this operation, some 
routines are provi<Ied which are windows specific, these are referred to as Windows- 
sp(!cific Extension Fnnetions. These extended APIs allow message-based asynchronous 
acc(;.ss to network events. “Windows Sockets ” document of latest version is available in 
electronic form, requests for the same is to be addressed to winsock-request® ftp. com. 



Appendix B 
LINUX 


Linux ‘ is a coinplft uiy fm* rduiplenicntation of the POSIX spec, with SYSV and BSD 
{'Xtunsions (whicii moans it looks like Unix, but does not come from the same source 
(■<m1o haso), which is available in both source code and binary form. It was written by 
Linus IL 'lorvalds with help from various contributers on internet. 

Linux runs oiily on 38C/48G/Pfintium machines with ISA, EISA, PCI and VLB busses. 
Ports to otlu^r nuu‘hines, including MIPS, PowerPC, and PowerMAC, are under way 
an<l showing various amounts of progress 

Linux Features 

multitasking: several programs running at once. 

a) multiuser: stn'ernl usc'rs on the same machine at once. 

b) rtms in 380 protected nuKle. 

c) hus nuunory prtstetUion between processes, so tliat one program can’t bring the whole 
sysL'in down. 

<!)deman{l loads tixectitahles: Linux only reads from disk those parts of a program that 
are actually used. 

e) shared copy-on-writ<; pages among executables. This means that multiple process 
can use the same memory to run in. When one tries to write to that memory, that 
page ('IKB piece of memory) is copied somewhere else. Copy-oii-writc has two benefits: 
incrciising speed and decreasing memory use. 

f) virtual memory u.sing paging (not swapping whole processes) to disk: to a separate 
partition or a fil(! in the filesystem, or both, with the possibility of adding more swap- 
ping arcjis during runtime (yes, they’re still called swapping areas). A total of 16 of 
these 128 MB swapping areas can be used at once, for a theoretical total of 2 GB of 
useable swap space. 

g) a unified memory pool for user programs and disk cache, so that all free memory can 
be used for caching, and the cache can be reduced when running large programs. 

h) dynamically linked shared libraries (DLL’s), and static libraries too, of course. 

i) doe8 con! <lumi)S for j)OSt-inortem analysis, allowing the use of a debugger on a pro- 
gram not only while it is running but also after it has crashed. 


Uittp://www.math.uio.no/doc/Hnux/HOWTO/tekst /INFO-SHEET 
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jlmostly coinpatihh* with POSIX, System V, and BSD at the source level. 

k) all .si»urt'«‘ coiit' is availahh?, iiirhiding the whole kernel and all drivers, the develop- 
nuuit looks and all user programs; also, all of it is freely distributable. 

l) POSiX Job (hhiIwI. 
in)!>s(‘ndt>t»*nninals (ply’s). 

n)'r('171P networking, including ftp, telnet, NFS, etc. 



Appendix C 
RFC1155 


HFCn l5r,.SM! DEFINITIONS ::= BEGIN 

EXPOirrS EVERYTHING 

intenujt, directory, mgint, 

<‘xperi!neiital, private, enterprises, 

OBJECT-TYPE, ObjcctName, ObjectSyntax, SimplcSyntax, 
AppIicationSyntax, NotworkAddress, IpAddress, 

Counter, Gatige, TimeTicks, Opaque; 

thf^ path to the root 

internet OBJECT IDENTIFIER ::={ iso org(3) dod(6) 1} 

directory OBJECT IDENTIFIER ;:={ internet 1} 
ingint ()BJECT IDENTIFIER ;:={ internet 2} 
exp(!rimental OBJECT IDENTIFIER ::={ internet 3} 
private OBJECT IDENTIFIER ;:={ internet 4} 
enterprises OBJECT IDENTIFIER ::={ private 1} 

definition of object types 

OBJECT-TYPE MACRO ::= 

BEGIN 

TYPE NOTATION “SYNTAX” type 
“ACCESS” Access 
“STATUS” Status 

VALUE NOTATION value (VALUE ObjectName) 
Access ::= “read-only” 

I “read-write" 

I “write-only” 

I “not-accessible” 

Status ::= “mandatory” 
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i “optional” 
j “obsoloto” 

END 

luvHU's of objects in the MIB 

ObjectNanic ;:= 

OBJECT IDENTIFIER 

syntax of objects in the MIB 
Ohj<‘ctS.vntax ::= 

CH0'lCE{ 

simple 

Simph'Syntax, 

note that simple SEQUENCES are not directly 
iiK'nlioiHMl htne to keep things simple (i.e., 
prevent mis-use). However, application-wide 
types which are IMPLICITly encoded simple 
SEQUENCES may appear in the following CHOICE 

api)lication-wide 

ApplicationSyntax 

} 

SiinpleSyntax ::= 

cnoicE{ 

numl>er 

INTEGER, 

string 

OCTET STRING, 
object 

OBJECT IDENTIFIER, 
empty 
NULL 

} 

ApplicationSyntax ::= 

CHOICE{ 

address 

NetworkAddress, 

counter 

Counter, 

gauge 

Gauge, 

ticks 



riuu^'!’u‘k.s, 

arlihrary 

OpiUJIK* 

uiUvv applicalion-wido typra, ;is they are 
will he a(l<le(l hero 

} 

applieat ion-wide tyi)os 

NetwurkAckiress :;= 

CliOICE{ 
intiuuot 
Ip Address 

} 

IpAddress ::= 

[APPLICATION 0] - in network-byte order 
IMPLICIT OCTET STRING (SIZE (4)) 

Counter 

[APPLICATION 1] 

IMi^LICIT INTEGER. (0..4294967295) 

Gaiige :;= 

[APPLICATION 2] 

IMPLICIT INTEGER (0..4294967295) 

TinieTicks ::= 

[APPLICATION 3] 

IMPLICIT INTEGER (0..4294967295) 

()pa(jue ::= 

[APPLICATION 4] - arbitrary ASN.l valnc, 

IMPLICIT OCTET Sl’IllNG - “double-wrapped” 

END 



Appendix D 


RFCH57 


Hl-(’nr.7-SNM!' DKFINITIONS ::= BEGIN 
IMPOBTS 

OlijcftNunu', 01)J(H;tSyn{.ax, NetworkAcIdrcss, IpAddrcss, TirneTicLs 
FHOM H.l-Cll55-SMIi 

mossajfo 

Message :;= 

SEQUENCE { 

vHusioii - version- 1 for this RFC 
INTEGER { 
version- 1(0) 

community - coniimmity name 
OCTET STRING, 

<lata ~ o.g., PDUs if trivial 

ANY ~ authentication is being used 

} 

- protocol data units 

PDUs :;= 

CHOICE { 
get-request 

GetRequest-PDU, 

get-next-request 

GotNextRequest-PDU, 

get-response 

GctRcsi)onse-PDU, 

set-request 

SetRequost-PDU, 
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Trap-PDU 

} 

th(‘ iudiviciuai i^DU.s an<l commonly used 
data types will he defined later 


(l(‘tHeque.st-PDlJ ::= 

K'] 

IMPLICIT SEQUENCE { 
rt'<jue.st.-id 
HetpiestlD, 

error-status always 0 
KrrorStatus, 
enttr-ind<?x always 0 
harorlndex, 
varial>ie-i)indinfts 
X'arBindList 
} 

(Jet NextRecpiest-PDU ::= 

( 1 ) 

IMPLICIT SEQUENCE { 
re<{uest-id 
PequostlD, 

errt)r-st,atus always 0 
I'JrrorStatiis, 
(U-r()r-iti(I(‘x •• always 0 
Errorlmh'x, 
varial)le-hindiugs 
VarBindList 
} 

SctRequost-PDU ::= 

[3] 

IMPLICIT SEQUENCE { 
ro(}uest-id 
IlequestID, 

error-status - always 0 
ErrorStatus, 
error-index - always 0 
Errorindex, 
variable-bindings 
VarBindList 

} 
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Tiap-PDU 

l-s] 

IMPLICIT SEQUENCE { 

ontfrpriKP - type of object generating 

-- trap, see sysObjectID in [5] 
OBJECT IDENTIFIER, 
agent-acidr - address of object generating 
NetworkAddress, - trap 
generic-trap generic trap type 
INTEGER { 

(•oldStart(()), 

\var!nStart(l}, 

liiikDown{2), 

linkUp(3), 

jiuthenticationFaiIure(4), 
egpN<aghborLoss(5) , 
euterpriseSpecific(6) 

.si>ccirn:-trai) -- .specific code, present even 
INTEGER, - if generic-trap is not 

- enterpriseSpecific 

tiuic-stamp - time elapsed between the last 

TinicTicks, - (re)initialization of the network 

- entity and the generation of the 
trap 

variable-bindings - ’’interesting” information 
VarBindList 


variatilc bindings 
VurBind :;= 

SEQUENCE { 
name 

ObjcctNaine, 

value 

ObjectSyntax 

} 

VarBindList :;= 

SEQUENCE OF 
VarBind 


END 



Appendix E 

GLOSSARY 


Abstract Syntax Notatt^,, i /-aoktin a ■ 

ASN I is used in nai ^ language used for defining datatypes. 

ASN.l 1. u.cd m osi standards and in TCP/IP network management specifica- 


access mode A MlB access level of READ-ONLY, READ-WRITE , WRITE-ONLY 

t -t i.nrriVi««, translating a Network Layer address 

to a tairesiHijuinig physical address for a device. 


agent Softwaic that enables a device to respond to manager requests to view or 
update Mib data and sends traps reporting problems or significant events. 

Application Programming Interface(API) A set of routines that enable a pro- 
giainnui ■<> use computer facilities. The socket programming interface and the 
transport Inyi'r interface are both APIs used for TCP/IP programming. 

Asynchronous conmnmication Character-oriented communication in which char- 
acters are dehmited by start and stop bits. 

Authentication Proof of the identity of sender of a message. 

Basic Encoding Rules(BER) A set rules for translating ASN.l values into a stream 
of octets to be transmitted across a network. 


Berkeley Software Distribution(BSD) UNIX software which includes TCP/IP 
support. 


Bridge A device that connects two or more physical network. 

Client-server Flic model of interaction in a disributed system in which a program 
at one site sends a request to a program at another site and awaits a response. 
The requesting program is called client and the program satisfying the request is 
called a server. 


Commuriity Formally, a pair of agents with a set of application entities. Its purpose 
is to identify valid sources for requests and limit the scope of data that can be 
accessed. 
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Conununity Nauic Used like a password in message, validating the right of sender 
to access MIB data with a requested operation. 

Constructed type A composite datatype, such as SEQUENCE. 

Datagram The IP Protocol Data Unit. 

Encapsulation The technique used by layered protocols in which a lower level pro- 
tocol accepts a message from a higher level protocol and places it in the data 
portion of the low level frame. 

Exterior Gateway Protocol(EGP) A protocol used to advertise the set of networks 
that can be reached within autonomous system. EGP enables this information 
to be shared with other autonomous systems. 

fragmentation Partitioning of a datagram into pieces. This is done when data- 
gram is too large for network technology that must be traversed to reach the 
destination. 

Gateway An IP router. 

Group A named set of closely related MIB definitions within a module. 

Internet Architecture Board(IAB) Board that oversees the Internet protocol 
development and standardization. 

Lexicographic order Order of variables in the MIB tree, based on comparing OB- 
JECT IDENTIFIERS from left to right until the numbers differ in a position. 

Management Information Base (MIB) A logical database made up of the config- 
uration, status and statistical information stored at a device. 

Manager Software in a network management station that enables the station to send 
requests to view or update MIB values. 

Maximum Transmission Unit (MTU) The size of the largest datagram that can 
be delivered across a particular path. 

MIB-II A set of managed object definitions aimed managing TCP/IP based internets. 

monitor A device that listens to all traffic on LAN or on a wide area link, gathering 
statistics, and capturing traffic that matches some specific criteria. 

multihomed host A host attatched to two or more networks, and therefore requiring 
multiple IP addresses. 

OBJECT IDENTIFIER A string of numbers derived from a global naming tree, 
used to identify an object. 
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j)Urt.y A ju*(\vuik lunuagi'itH'nl. or nuum(',('r rok;. Soiih! <:(>nuiumi{;a.U; 

without, nuthfutication, some use authentication, and some use both authentica- 
tion ami encryption in order to protect the privacy of data. 

port imniber A 2*t)c;tet binary munhor idcntificatifying an upper- level user of TCi^ 

primitive Typc( ASN.l) A basic datatype such as an INTEGER or OCTET STRING. 

Requests for Comments(RFCs) A set of documents containing Internet protocols 
asid discussions of related topics. These documents are available online at the 
Network Information Center. 

router A system \ised to connect separate LANs and WANs to an internet, and route 
traffic between the constituent networks. 

socket The abstraction provided by Berkeley 4BSD UNIX that allows an application 
to access tiie TCP/IP protocols. It can be viewed as a pairing of an IP address 
and a port number. 

TCP The TCP/IP standard transport level protocol that providtis the reliable, full 
duplex, stream service on which many application protocols depend. 

UDP The TCP/IP standard protocol that allows an application program on one 
machine to send a datagram to an application program on another machine. 
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